The present invention relates generally to computing systems, and more particularly to a method and apparatus for providing collaboration between applications operating in an information system.
Corporations have spent billions of dollars a year to implement custom, standalone information systems that address specific business domain functionality requirements such as accounting, payroll, manufacturing, and distribution. By creating these separate, standalone systems, each individual section of the business process became isolated from the others.
Over time, Corporate Information Technology (CIT) departments began shifting away from in-house development of these custom systems and have attempted to minimize costs by purchasing enterprise applications on the outside. Enterprise applications are more generic, providing general business functionality in a pre-packaged product. Typically, enterprise applications include heterogeneous combinations of application systems, hardware platforms, operating systems, third- and fourth-generation languages, databases, network protocols, and management tools. While these applications bring tremendous benefits to the companies that implement them, on an enterprise level, they only exacerbate the proliferation of xe2x80x9cprocess islandsxe2x80x9d because they are not readily integratable.
Stand-alone enterprise applications provide powerful tools for handling many business processes. However, some functionality is often duplicated in separate applications, driving up the cost when bundling enterprise applications. Custom functional integration between enterprise applications, while desirable, is generally cost prohibitive, and defeats the benefits of the make-versus-buy decision to purchase the enterprise application in the first place. Tool and middleware vendors offer solutions for data integration, but not function integration, and even those solutions require significant custom coding to implement.
A collaboration system is described in commonly owned U.S. Pat. No. 5,913,061 entitled xe2x80x9cModular Application Collaborationxe2x80x9d to Prashant Gupta et. al., filed Jan. 8, 1997, the contents of which are expressly incorporated herein by reference. Therein a modular application collaborator was described for providing inter-operability between applications. The collaborator included two or more connectors for communicating with applications and an interchange server. The interchange server was a non-distributed single server and provided an object-oriented, multi-user transactional execution environment for execution of collaborations. The interchange server included an application collaboration module and service module. The service module transferred messages between connectors and the application collaboration module. The application collaboration defined the inter-operability between two or more applications.
The collaboration system included a simple object model. A single, generic format for each business object in the system was provided. Each application connector included an application specific version of that business object. The application collaboration only deals with the generic forms of the objects. This results in an n-1-n conversion scenario for any object type.
The primary shortcoming of this model is the large and monolithic character of the generic object. Having a single generic object requires a great deal of cross-application analysis in order to extract the xe2x80x9cbest practicexe2x80x9d combination of attributes, and is close to impossible in some cases. In addition, the collaborations/business objects, were not inheritable/extensible. The lack of inheritance makes it difficult to design business objects that are specific to subject areas and yet share several common attributes.
In addition, the interchange server was not completely componentized. This limited the ability to plug and play third party components into the server, and also limited the availability to take advantage of third-party services usable by well componentized systems.
The proposed object transformation scheme relied on a third party tool that provided inadequate programmatic interfaces, causing inconsistency between the specification of a business object and the specification that the tool used, inadequate diagnostic support during execution, and poor performance.
The communication between the connectors and interchange server always used xe2x80x98store and forwardxe2x80x99 message queues, even when xe2x80x98store and forwardxe2x80x99 facilities were not needed. This also limited data throughput. A proper versioning mechanism that allows a way to specify version dependencies between components and a way to manage the dependencies was not provided by the existing system.
As described above, the basic object model proposed was a simple one designed to create generic business objects. However, difficulties arise when implementing a generic object. Turning to a particular example, let us examine a generic customer business object. Some Customer Interaction Management (CIM) or Enterprise Resource Planning (ERP) applications define customer objects and store a customer""s address data as dependent records of the customer object. In other words, the addresses do not exist independently of the customer data and can be accessed only through their parent customer object. These addresses are not used by more than one customer object (xe2x80x9cSoldToxe2x80x9d customer). Examples of applications that store information in this way are applications produced by Baan, Oracle, Vantive, and Trilogy.
Alternatively, some CIM and ERP applications store customer data in a hierarchy of independent objects. The customer role at the top of the hierarchy represents the customer with whom an order can be placed. This xe2x80x9cSoldToxe2x80x9d customer links to other customer objects through roles. Examples of roles include a xe2x80x9cShipToxe2x80x9d, xe2x80x9cBillToxe2x80x9d and xe2x80x9cPayerxe2x80x9d roles. FIG. 1 illustrates a typical SoldTo customer with its relationship to other customer objects.
In these applications, the subordinate customer objects can be associated with more than one customer object (xe2x80x9cSoldTo customerxe2x80x9d) and can be created before the customer object is created. Because the customer object stores the links to its related customers, the subordinate customers must exist before the customer object can contain the links to them. Examples of applications that store information this way are applications produced by SAP, PeopleSoft, and Clarify. Problems arise when trying to create a generic business object that supports both of these types of object definitions.
An object model and system is provided wherein customer""s address data or subordinate customers are represented as a separate xe2x80x9ccustomer partnerxe2x80x9d business object. Synchronization occurs as a multi-step process in which the customer business object is created, customer partner business objects are defined and the relationships between the Customer and its related customer partners are updated. The Customer and customer partner business objects are created so that the relationship between a customer object and its subordinate customer or address is always stored in the parent object (that is, the Customer business object references the customer partner business object). Applications that store the relationship in the child object are configured to trigger an application-specific business object that maps to the customer business object.
The current business object model has been extended to support a hierarchy of objects, providing the ability to inherit and extend more generic business objects into those specific for a subject area. In addition, business objects provide multiple views, allowing different collaborations to view the same object in different ways. Collaborations support inheritance to allow them to be inherited and extended.
The component model proposed herein allows the subsystems (services, collaborations, connectors) in the interchange server to adhere more strictly to a component model, interacting with other subsystems via well-defined interfaces. This allows services from third-party vendors to be plugged into the infrastructure easily. The component model adopted is along the lines of the Enterprise Java Bean model.
The distribution model consists of a distributed object bus that provides a single namespace for multiple interchange servers, and a set of distributed services (object transformation, transaction, etc.). Content-related components such as collaborations and connectors execute in their own containers that interact with the bus to avail the services.
The services provided by the interchange server are enhanced to be more robust and easily usable. These include an object transformation service, a concurrency service for optimal concurrent execution of collaborations, a life cycle management service, a localization service to support multiple locales, and a versioning service to help specify version compatibility matrices
Lighter weight mechanisms are provided whenever xe2x80x98store and forwardxe2x80x99 message queues are not required.